Ping @ndarilek for review.

Looks like the alt text remains in the current version of this PR?

I do of course want the image back, but I'm not OK with removing the alt text.

I'm not sure what the intent was here.

I'd like to clarify that. Are you unsure what alt text is, unclear on its utility, or something else? Genuinely not trying to be sarcastic, but I'd rather fix this than remove accessibility, if only so our examples do a good job of it.

I understand what alt text is but I haven't looked at the AccessKit pr before today and I don't understand the intent behind this implementation.

With TextStyle::default() no text is drawn, and no image is drawn because the zero height of the text node is inherited by the parent image node as well because of how the measurefunc works.

Got it.

For context, I'm a blind screen reader user. When I explore this UI with NVDA (my screen reader) running, I can find the Bevy logo when reviewing screen content, and am told that it is the Bevy logo. Admittedly that isn't super useful in this toy example, but it does at least display what I'd like us to consider a best practice, and is useful for discussing screens and UIs in an inclusive way (I.e. someone saying "X is true on the screen with the Bevy logo" might not mean anything to me otherwise.)

It's OK if the text isn't displayed--at least, it is until we've got a better UI that displays alt text similar to how HTML does. For the moment I needed some way to attach the alt text to an image, and making it a child node seemed to accomplish that. Ideally in the future we'll have a more fleshed-out UI component that includes alt text/widget descriptions directly and unambiguously.

I can't of course speak to how this PR appears visually but I've verified that the UI example still presents alt text correctly. Apologies for breaking the image, and thanks for the fix!

I've only been looking at the accessibility module for a few minutes so this might be nonsense, but would a change something like this be acceptable:

#[derive(Component)]
pub struct AltText(pub String);

fn image_changed(
    mut commands: Commands,
    mut query: Query<
        (Entity, &AltText, Option<&mut AccessibilityNode>),
        (Changed<UiImage>, Without<Button>),
    >,
) {
    for (entity, alt_text, accessible) in &mut query {
        let name = alt_text.0.clone().into_boxed_str();
        if let Some(mut accessible) = accessible {
            accessible.set_role(Role::Image);
            accessible.set_name(name);
        } else {
            let mut node = NodeBuilder::new(Role::Image);
            node.set_name(name);
            commands
                .entity(entity)
                .insert(AccessibilityNode::from(node));
        }
    }
}

And we would add the AltText component to the ImageBundle.

This sort of design makes sense to me: you should be able to read both explicit alt text and text from Text components.

For the moment, I've constrained the Image to a fixed size so it will display correctly with the text as a child.

I'm absolutely in favor of adding more accessibility-specific components and fields, but I'd like to be intentional about it as part of comprehensive UI overhauls rather than creating individual, separate components. I made that mistake by introducing a Label component, which in retrospect I probably should have just handled with a custom NodeBuilder.

All that is to say, if we can fix this without introducing a new component, I'd be more in favor of that, particularly with a 0.10 release imminent.

Had some further thoughts about this:

• Perhaps another option for alt-text might be for assets to have an optional description string? Then users could add a description to media assets like images and sound effects that could be used in their place when necessary. A user would add an ImageBundle like now and if the player of the game is using a screen reader the image systems could automatically retrieve the description string instead of an image. That might also be useful for prototyping and debugging, not just accessibility.

• I've replaced the ImageBundle with a NodeBundle that has a white background color and a UiImage component, and added a comment explaining why. I think this is okay and allows for the example to be included in 0.10 if there isn't time to find another solution for alt-text. It provides a demonstration of how to spawn a UI node with an image and children without errors.

You say

I've replaced the ImageBundle with a NodeBundle that has a white background color and a UiImage component, and added a comment explaining why. I think this is okay and allows for the example to be included in 0.10 if there isn't time to find another solution for alt-text. It provides a demonstration of how to spawn a UI node with an image and children without errors.

But I don't see a comment explaining it.

I'm not sure what to happened to the comment, perhaps I forgot to add it to the commit. I'll fix it.

I assume it's because the text is white and therefor invisible on white background? Not too hot on that, what made you chose
that over using Visibility::Hidden?

This PR was written before the change that added a default font and TextStyle::default() wouldn't draw any text.

A NodeBundle can display an image as long as you give it a UiImage component but you to have set a BackgroundColor as NodeBundle is transparent by default.

Could you add a "fixes #8805" in the PR description?